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ABSTRACT 

As part of the Phase 1 efforts of NASA’s UAS-in-the-NAS Project a task was initiated to explore the merits of 
developing a system simulation capability for UAS to address airworthiness certification requirements. The core of 
the capability would be a software representation of an unmanned vehicle, including all of the relevant avionics and 
flight control system components. The specific system elements could be replaced with hardware representations to 
provide Hardware-in-the-Loop (HW1TL) test and evaluation capability. 

The UAS Systems Integration and Validation Laboratory (UAS-SIVL) was created to provide a UAS-systems 
integration, validation, and diagnostics hardware-in-the-loop simulation capability. This paper discusses how SIVL 
provides a robust and flexible simulation framework that permits the study of failure modes, effects, propagation 
paths, criticality, and mitigation strategies to help develop safety, reliability, and design data that can assist with the 
development of certification standards, means of compliance, and design best practices for civil UAS. 
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BACKGROUND 

The Federal Aviation Administration (FAA) and the civil Unmanned Aircraft System (UAS) stakeholder community 
have completed a number of initiatives to guide and facilitate the phased accommodation of civil UAS operations in 
the National Airspace System (NAS). These initiatives form the basis for near-term limited civil and public UAS 
operations as well as the basis for longer-term full integration of civil and public UAS operations in the NAS. These 
initiatives include a UAS civil roadmap produced by the FAA (2013), UAS civil CONOPs by the FAA (2012), and a 
UAS ARC Implementation Plan by the UAS Aviation Rulemaking Committee (2013) that is designed to implement 
the UAS roadmap. 

Figure 1, from UAS ARC (2013), presents a summary of proposed major activities and resultant outputs from the 
ARC Implementation Plan. 


System 
Certification 


Major A ctivities 

System Certification Criteria & Methods of Compliance (MOC) 

• Develop UAS Design Criteria Handbooks (Airplane. Rotorcraft , Airship) 

• Conduct Certification Pathfinder activities (Airplane. Rotorcraft. Airship) 

• Conduct Restricted Certification Program 

• Develop SAA & C2 Performance Standards 

• Update applicable FARs and develop training courses 

Safety Criteria & Methods of Assessment (MOA) 

• Develop FAA Policy Paper establishing the vision for UAS safety 

• Determine UAS Safety Criteria (i.e. Appropriate Levels of Safety & Allocations) 

• Determine Safety MOAs (i.e. Methodology for Proving Safety & Tracking Metrics) 

• Develop interim safety guidelines and update /develop Safety Criteria & MOAs 

Security Criteria & Methods of Assessment (MOA) 

• Adopt/adapt security concepts. & scope work by conducting high-level security assessments 

• Identify security certification strategies, establish scope & approach for UAS security assmts 

• Identify security threats, vulnerabilities, hazards, & risk mitigation strategies/solutions 

• Establish essential security requirements to be met throughout the UAS life cycle 
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Pilot / Crew Qualifications 

• Develop crew qualifications and instructor requirements 

• Develop test standards for pilots, crew and instructors 

• Establish medical and simulation certification requirements 

• Publish final crew, medical and FTD qualification & certification requirements 
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Figure 1: ARC Implementation Plan Proposed Major Activities and Resultant Outputs 
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The proposed activities fall into three major categories that roughly correspond to today’s regulatory framework for 
manned aircraft, that being regulations related to certification of the vehicles and their systems (14CFR Parts 21, 23, 
25, 27, 29), regulations relating to pilot/crew certifications (14CFR Part 61), and regulations relating to operational 
certifications (14CFR Parts 91, 121, 125, 135, etc.). 

As part of the overall effort to facilitate the integration of UAS into the NAS, the National Aeronautics and Space 
Administration (NASA) currently has underway a two-phase program to develop and demonstrate technologies that 
will assist the FAA and the UAS stakeholder community with various elements of the roadmap and implementation 
plans. 

As part of Phase I of the NASA research efforts, a research capability was developed at the NASA Langley 
Research Center (LaRC) designed to address some of the issues identified in the “System Certification” category of 
the implementation plan. In particular, the research capability, currently called the UAS System Integration and 
Validation Laboratory (UAS-SIVL), was designed to address issues associated with civil UAS avionics and flight 
control system reliability, safety assessment methodologies, functional hazard identification, failure modes and 
effects, and design best practices to facilitate the certification of these systems. 

As described later, the capability consists of a full simulation of all important elements of a civil UAS, including the 
vehicle (aero, propulsion, stability, control, mass properties, etc.) and its systems, command and control links, and a 
generic enclosed ground control station. Additionally, a simulated environment to allow the incorporation of Visual 
Line of Sight (VLOS) operational segments was also included. The capability currently includes a full software 
representation of a high-end turbine powered UAS as well as a software representation of a small reciprocating 
powered UAS in the 100 pound weight range. The small UAS representation also includes a Hardware in the Loop 
(HW1TL) capability that integrates typical avionics and flight control hardware elements for this class of vehicle 
into the simulation. 

The capability has thus far been used to study human factor considerations in the control of small UAS during 
VLOS operations and future studies are planned for collecting reliability and failure data on typical small UAS 
avionics and flight control systems and components. 

The capability includes network interfaces that will allow the integration of the capability into other larger 
simulations or the remote operation of the simulation. The purpose of this paper is to provide a detailed description 
of this capability. 


UAS-SIVL OVERVIEW 

The UAS Systems Integration and Validation Laboratory is the primary component of NASA Langley’s Simulation 
Development and Analysis Branch’s (SDAB) UAS-Systems Integration, Validation, and Diagnostics Hardware in 
the Loop Modeling and Simulation Capability. The UAS-SIVL was designed to include all of the major components 
of a civil unmanned aircraft system to include onboard systems, ground-based systems such as the ground control 
station, and the command and control link. This section provides an overview of those components with a discussion 
of how they fit together to create the UAS systems simulation capability. 

The component at the core of the capability is the software simulation framework that executes on a real-time 
capable computer. The simulation includes the mathematical representations of representative unmanned vehicles 
built on the Langley Standard Real-Time Simulation in C++ (LaSRS++) framework. More information on the 
simulation framework and the vehicles currently modeled are provided in the next section. 

The simulation computer system is a high-end Personal Computer (PC) running Scientific Linux that includes a GPS 
synchronized Time and Frequency Processor to provide deterministic cycle timing for real-time processing. 
Representative data input and output capability, such as analog, digital, PWM, serial, Ethernet, and CAN BUS are 
available. The input and output devices and associated data busses or cables were selected to mimic representative 
UAS systems and to generate as little latency as possible. Representative latency can be modeled in software to 
more accurately depict the vehicle being simulated. 

The simulation can also be run in fast-time, without hardware in the loop, for rapid processing of multiple scenarios, 
such as failure scenarios where the failure applied to a given signal is modified slightly for each data run, and thus 
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can be used for Monte Carlo analysis. This technique is particularly useful when examining failure modes and 
effects where hardware and its associated response time do not affect the issue being examined in the simulation. 

The Hardware-in-the-Loop capability currently utilizes a single avionics test bed, which was designed for mounting 
representative avionics components, such as servos, so that they can be commanded to move as if in flight. The 
servo mounting portion of the test bed includes potentiometers to read actual servo arm positions and adjustable 
springs to represent the aerodynamic loading on the control surfaces as they are deflected. A prototype avionics test 
bed was built for proof-of-concept and a more versatile platform is under design. The new test bed is being designed 
to fit into environmental test chambers available at NASA’s Langley Research Center. Other components, such as 
avionics units, can also be mounted on the test bed for testing in the environmental chambers. The HWITL 
capability is discussed in detail later in this paper. 

The Ground Control Station (GCS) consists of a PC driving four display units. The four displays are generic and can 
be configured for various crew configurations, such as one UAS pilot, two UAS pilots, or one UAS pilot and one 
payload operator (Figure 2). The open source software product, HappyKillmore’s Ground Control Station, is 
currently used to create a generic graphical user 
display including a Google Maps/Earth interface to 
display the model path and track along with a view 
of the vehicle. Multiple views are available such as 
a chase camera view, antenna tracking view, first 
person view, and overhead view. This GCS 
software communicates with the simulation 
computer over an Ethernet interface. State data 
from the simulation provides position and attitude 
data to drive the vehicle display and to drive 
gauges for pilot displays. Waypoints can be 
provided by the simulation or created at the GCS 
and modified during flight by the GCS operator. 

The design of the interface between the GCS and 
the simulation will allow the generic GCS displays 
to be replaced with user-defined displays or for the 
simulation to be operated remotely from a user’s 
GCS via a number of available simulation networks 

As part of the overall UAS-Systems Integration, Validation, and Diagnostics HWITL Simulation Capability, a 
Visual Line-of-Sight (VLOS) simulation capability was created using an existing panoramic screen with a horizontal 
field-of-view of 135 degrees and a vertical field-of-view of 67.5 degrees. The field of view subtended by the 
panoramic screen can be rotated in azimuth and elevation to provide full horizon-to-horizon coverage from a 
preselected observer’s location. Six interlaced projectors are used to display the environment. A visual model of the 
unmanned vehicle is driven by the simulation and can be controlled either from the GCS or from a standard RC 
controller typically used for small UAS (sUAS). This immersive environment provides visualization of the vehicle 
in flight and allows visual control of a UAS to be included as an option in hazard mitigation strategies. The VLOS 
environment was used in a study investigating the effects of displays on the pilot’s ability to acquire and loiter over 
waypoints. 



UAS VEHICLE SIMULATION 

Simulations were developed for two unmanned vehicles being tested by other organizations at NASA, Langley 
Research Center as part of the Airborne Subscale Transport Aircraft Research (AirSTAR) program. These vehicles 
were chosen because of the abundance of flight data available to validate the simulation model, which can be 
important when considering the use of a simulation to collect some types of safety-related data. A baseline generic 
UAS simulation model was created to house the simulation features to be shared by all future unmanned vehicle 
models utilizing the simulation capability 
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The baseline generic Unmanned Aerial Vehicle (UAV) model was built using the LaSRS++ framework, which is 
described by Leslie et al. (1998). The object-oriented design utilized in the LaSRS++ framework makes it an ideal 
basis on which to build the UAS simulation models. The LaSRS++ framework allows for a high degree of software 
reuse when creating new vehicles to ensure that all of the basic features are available to any new UAS vehicle 
simulation model. Madden (2001) examines reuse in LaSRS++ -based projects. 

The only new software that is needed to build a new model is that which defines the characteristics of the vehicle 
being modeled, such as the vehicle’s mass properties, control laws, engine model, aerodynamic model, and/or the 
control surface models, and interfaces to any new hardware. The vehicle-specific models use inheritance to utilize 
existing features of the baseline models that are common to all vehicles. This vehicle-specific definition can then 
utilize all of the other capabilities of the LaSRS++ framework such as atmospheric models, failure models, and 
sensor models. The object-oriented design approach with the use of hardware abstraction, as examined by Kenney et 
al. (1998), facilitates the creation of UAV models that allow for the relatively easy replacement of software systems 
with their counterpart hardware components. 

The following sections include more detailed descriptions of the primary components of the UAS SIVL, which are 
the HWITL test bed and the UAV simulation model. Some of the core software systems are discussed later in this 
paper including how they work together to simulate the unmanned vehicle. There is also a discussion of the 
hardware components that are currently part of the HWITL capability and how these components are used in the 
simulation. 

Hardware-in-the-Loop Avionics Test Bed 

The initial HWITL avionics test bed was designed to hold any hardware components to be tested and to provide 
communications interfaces to the simulation computer. The initial proof-of-concept avionics test bed is currently 
being redesigned to fit inside of existing environmental chambers at the NASA Langley Research Center. This will 
allow hardware components to be tested in a more realistic flight environment if required. 

The HWITL capability of the UAS-SIVL currently includes a Commercial-Off-the-Shelf (COTS) integrated UAS 
avionics unit and some COTS servos. The avionics package is referred to as integrated because it contains multiple 
integrated sensors and functions contained in a single package as opposed to independent units for each 
sensor/function. The avionics unit and servos are widely used in small to medium sized UAVs. Since one purpose of 
UAS-SIVL is the collection of statistically-relevant reliability and failure data on generic UAS systems, the 
equipment manufacturers are purposely not named in this paper. This integrated avionics unit contains an autopilot, 
flight sensors, and navigation capability. Since the UAS-SIVL does not include a motion platform to move the 
avionics unit as if it were in flight, simulated sensor signals are provided to the autopilot portion of the avionics unit. 
This allows the autopilot to perform as it would in flight and to generate surface and throttle commands for the 
vehicle. A flight plan consisting of waypoints can also be provided by, and/or modified by, the simulation. 

The avionics test bed was also designed to hold servos that can be driven by the simulation or by the avionics unit. 
Adjustable springs are attached to the servos to provide simulated aerodynamic loading that would be felt as the 
surface being driven by each servo deflects. The springs are set to generate up to half the load limit specified for the 
servos being tested. Potentiometers are attached to the servos to provide the simulation with an actual position 
reading corresponding to the commanded position. The use of independent feedback on servo position provides an 
independent measure of servo failure that can then be used to guide simulation protocols, such as going into “hold” 
mode where the simulation is frozen in time when a failure occurs. 

Vehicle Systems 

The primary simulation vehicle systems discussed in this paper consist of the control system, the propulsion system, 
the aerodynamic system, and the sensor system. It is not the intent of this paper to provide a detailed discussion of 
these systems, but to show how the systems interact with each other and with the hardware components. 

The software representations of the control systems for the small UAVs currently modeled in the UAS-SIVL consist 
of a “stick-to-surface” mode and an autopilot mode. The stick-to-surface mode converts pilot inputs from a joystick 
or a hobbyist Radio Control (RC) box to surface commands to fly the model. The software autopilot mode generates 
surface commands so that the model will follow a flight path consisting of waypoints, altitudes, and speeds. The 
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software autopilot mode also includes a software representation of an auto-throttle to drive the throttle lever to 
control engine performance. 

When the simulation is in autopilot mode, the servos described above can be driven either by the surface commands 
generated by the software representation of the autopilot, or from the commands generated by the hardware 
autopilot. As mentioned above, the actual servo responses to these commands are measured by the potentiometers 
attached to each servo. The software representation of the control system also includes mathematical models of the 
servos that can produce a simulated servo response to a surface command. 

Each of the UAV simulation models currently implemented in the UAS-SIVL includes an extensive aerodynamic 
model that is used to generate the forces and moments felt by the vehicle. Along with simulated sensor data, the 
control surface positions, generated either by the software servo models or by correlating the potentiometer readings 
to what would be the resulting surface positions, are used as inputs to the aerodynamic model. 

Each of the UAV simulation models currently implemented also includes an engine model that is part of the 
propulsion system object. Throttle commands generated by the software auto -throttle implementation or by the 
hardware avionics unit are fed to the propulsion system where forces and moments are computed that would be 
generated by the engine. As shown in Figure 3, the forces and moments from the aerodynamic model and the 
engine model are inputs to the equations of motion that generate the resulting state data for the vehicle. 



Figure 3: UAS-Systems Integration, Validation, and Diagnostics HWITL Simulation Capability 


The UAS-SIVL simulation capability includes data recording of time-history data and discrete events such as faults 
or failures. All data values that are in the simulation, including any values generated by external systems, can be 
recorded at the frame rate of the simulation for later analysis. For the current UAS models, the cycle time for real- 
time simulations is twenty milliseconds, or fifty frames per second. Using the real-time clock, other frame rates are 


2014 Paper No. 1462 Page 6 of 9 










MODSIM World 2014 


achievable as required. The data can also be recorded at multiples of the cycle time to avoid huge data files. Data 
values available in the simulation can also be displayed alphanumerically or as graphical representations for real- 
time data monitoring. 

A feature of the LaSRS++ framework that is extensively utilized in the UAV simulation is the sensor system. 
Multiple sensor models have been created over the years using the LaSRS++ sensor system that are important 
components of the UAV simulation. Some examples of sensor types used by the UAV simulation are those that 
would be found in the type of avionics units found on unmanned vehicles such as accelerometers, rate gyros, angle 
of attack and sideslip vanes, air relative velocity, and altimeter sensors. The Global Positioning System (GPS) sensor 
model and Automatic Dependent Surveillance-Broadcast (ADS-B) system are also available to the UAV simulation. 
An aspect of the LaSRS++ sensor system that makes it ideal for use in the UAS-SIVL is its built-in sensor failure 
modeling capability, which is discussed in more detail in the next section. 


FAILURE SIMULATION AND MONITORING 

Intentional and incidental faults, failure modes, failure effects, and reliability data may be of significant interest to 
researchers interested in UAS certification and safety case generation. UAS-SIVL has been specifically designed to 
study faults, failures, and reliability of either individual UAS components or entire UAS systems, in addition to 
being able to provide conventional simulation of UAS performance on simulated mission profiles. 

UAS-SIVL includes the capability of running a simulation of a UAS flying a representative civil mission, such as 
surveillance of a high-value asset, under representative atmospheric conditions, such as turbulence and/or winds. 
This capability allows the collection of realistic reliability data by measuring the time and deflection spectrum over 
which the components/sy stems are operated before exhibiting some sort of fault or failure. Various monitoring 
mechanisms are used to determine that a failure has occurred. For instance, the difference in the commanded servo 
position and the actual measured position, accounting for rate and position limitations of the servo. When the 
difference between the commanded and resulting position is outside of an expected range, the simulation will follow 
a user-specified protocol, such as stop running, or continue running and record the time at which the failure 
occurred. 

Simulated Failures 

UAS-SIVL was designed to study failure modes, and failure effects. To this end multiple types of simulated failures 
can be injected at various points to determine the effect of the failure on the various components or on the UAS as a 
whole. Some of the potential failure injection points are illustrated by the F inside the red circle in Figure 3 above. 
The LaSRS++ simulation framework includes sensor failure models discussed in the paper by Neuhaus (2001). The 
same failure modes available to the sensors are also available to the servo models. 

One example study conducted with one of the simulated UAVs in the UAS-SIVL assumed each aileron was driven 
by its own servo, as opposed to both ailerons being driven by one servo through a common bell crank, a common 
industry practice. A failure was introduced simulating the single aileron to be stuck in the last commanded position 
and no longer moving as commanded. This failure resulted in the vehicle being able to complete the intended 
mission, but with the flight path not as well contained as when both ailerons were responding to commands. A 
similar failure was applied to the other aileron, which would also simulate a single servo for both ailerons, resulting 
in a catastrophic loss of control. Failure Mode, Effects, and Criticality Analysis (FMECA) of these failure scenarios 
demonstrates the potential effect of design choices on failure consequences and thus on reliability requirements. 

Other failure modes that are available in the UAS-SIVL include the application of various levels of noise to a 
simulated sensor signal such as a rate gyro, failure to a zero value, failure to the minimum or maximum signal level, 
or failure to a reverse value, such that the signal value is set to the negative of the original signal value. The failure 
options also include dynamic failures, such as oscillatory or randomly varying values. Since the simulation 
environment provides repeatability of all aspects of a mission, the effect of each failure on the system can be 
examined in depth by the researcher. 

Failure Monitoring 
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The section above describes how UAS-SIVL can be used to study the consequences of, and mitigations for, the 
intentionally inserted faults. The USA-S1VL capability can also be used to study the rate of occurrence of incidental 
faults, or faults that occur naturally as a result of repeated use of a component or system, in other words, reliability 
testing. Real-time failure monitoring, semi-autonomous operation, and user-selectable protocols for what happens 
when a failure is detected allow UAS-SIVL to be used for accelerated testing of UAS components and systems. A 
proof-of-test failure monitoring study was designed to look at the reliability of COTS servos by flying the 
previously-mentioned surveillance mission and continuously recording data while driving the servos mounted to the 
avionics test bed. A display was developed to graphically show servo commands and measured positions as well as 
the difference between the command and actual position so a researcher can observe servo performance during the 
test if desired. The simulation was set up to automatically switch from operate to hold mode upon failure detection, 
and remain in that state until human intervention occurs. At that point the simulation may be halted for examination 
of the hardware, or resumed to determine the ultimate outcome of the failure. 


EXTERNAL INTERFACES AND MISSION SCENARIOS 

The UAS-SIVL is part of the NASA Langley Research Center Flight Simulation Facilities and as such, it can be 
connected to all of the other facility simulators for combined multivehicle manned/unmanned simulation studies. 
Using the existing High Level Architecture (HLA) or the Test and Training Enabling Architecture (TENA) UAS- 
SIVL can participate in large-scale multivehicle simulations with other facilities at NASA LaRC as well as 
simulation facilities at other NASA Centers, DOD facilities, FAA facilities, commercial facilities, and university 
facilities. 

Through this networking capability, or using indigenous mission simulation capabilities such as the surveillance of a 
high-value civilian asset described previously, the UAS-SIVL can support full mission simulations including generic 
communications link representations and/or generic ground station simulation. Any hardware or software 
component can be substituted by a user, either onsite or remotely. The design of UAS-SIVL to study civilian use 
cases, vehicles, and systems means that none of the system design or data is classified. However, the Langley 
simulation environment, of which UAS-SIVL is a part, includes extensive capabilities for conducting classified 
simulations. 


SUMMARY 


As part of Phase I of the NASA’s UAS-in-the-NAS Project a UAS systems integration and validation laboratory was 
developed at the Langley Research Center. This laboratory is capable of providing a full systems simulation of a 
variety of UAS down to the subsystem and component level and includes a Hardware -in-the-Loop capability. The 
simulation includes full mathematical models of the vehicle mass properties, aerodynamic system, control system, 
propulsion system, and avionics systems, including sensors and auto flight systems. The laboratory includes a full 
suite of component and system-level fault simulations and an extensive data collection capability that makes it ideal 
for studies to support UAS airworthiness and operational certification issues, safety case quantitative evidence 
studies, and system safety studies. 
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